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Sir: 

This is an appeal of a Final Rejection under 35 U.S.C. § 103(a) of claims 1, 3-5, 7, 
9, and 1 1-15 of Application Serial No. 10/616,526, filed July 10 th , 2003. This brief is 
submitted by the appellants pursuant to a Notice of Appeal filed August 5 th , 2008, as 
required by 37 C.F.R. §1.192. 

The appeal brief fee of $510.00 is: 
I I Enclosed. 

I I Not required. (Fee paid in prior appeal.) 

E<] Charged to Deposit Account No. 09-0465 . A duplicate copy of 
this sheet is enclosed. 
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1. Real Party in Interest 

The Real party in interest is International Business Machines, Inc., the assignee of 
the above identified application. The inventors assigned their interest as recorded on July 
10 th , 2003, on Reel 014279, Frame 0668. 
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2. Related Appeals and Interferences 

There are no related appeals or interferences for the above-identified application. 
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3. Status of Claims 

Claims 3-5, 7, 9, 14, and 15 are pending and stand finally rejected, and are on 
appeal herein. Claims 2, 6, 8, and 10 are canceled. An amendment canceling claims 11- 
13 is awaiting entry. The claims on appeal are set forth in the Appendix of Claims. 
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4. Status of Amendments 

An amendment was filed after the final rejection mailed on June 9th 5 2008, and is 
meant to comply with 37 C.F.R. 41.37, canceling claims 11-13. This amendment is filed 
herewith, and is awaiting entry. 
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5. Summary of Claimed Subject Matter 

The invention herein relates to distributing and streaming of data, for accessing 
digital information, including audio, video, and business type information, at remotely 
stored locations and for communicating that information to a user's premise. Independent 
claim 1 recite a method for enhancing streaming operation in a distributed 
communication system providing communication links between a plurality of stream 
servers, a client machine requesting a particular media file, and a stream server selection 
unit. Independent claim 14 recites a device for enhancing streaming operation in a 
distributed communication system. Independent claim 15 recites a computer program 
product stored on a computer usable medium. 

In accordance with claim 1, a method is claimed for enhancing streaming 
operation in a distributed communication system providing communication links between 
a plurality of stream servers, a client machine requesting a particular media file, and a 
stream server selection unit. [Spec, page 4, lines 2-5]. A list of stream servers is retrieved 
from an Universal Description, Discovery, and Integration (UDDI) directory service 
[Spec, page 4, line 5; Fig. 2, element 204; Spec, page 5, lines 8-10.]. The list of stream 
servers is evaluated [Spec, page 4, line 5] by retrieving and considering the stream 
server's operating parameters [Spec, page 4, lines 1 1-15; Spec, page 8 lines 13-14], 
retrieving and considering the format(s) in which the media file is presented [Spec, page 8 
lines 14-15; Spec, page 9, lines 25-26], retrieving and considering preferences from the 
client [Spec, page 8 lines 21-22; Fig. 2 element 214], retrieving and considering the 
connectivity properties of the client [Spec, page 8 lines 23-24; Fig. 2, element 214], 
selecting one of the stream servers on the list [Fig. 2, element 232; Spec, page 9, lines 17- 
19], determining if the selected stream server can handle the media format of a first media 
file [Fig. 3 elements 335, 340], if the selected stream server can not handle the first media 
format, converting the first media file to a second media file having a second media 
format [Fig. 3 elements 345], determining if the selected stream server can handle the 
second media format [Fig. 3 elements 335, Spec, page 11, lines 21-25], if the selected 
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stream server can handle the second media format selecting the second media file [Fig. 3 
element 360, Spec, page 11, lines 17-19; Spec, page 12, lines 7-8], if the selected stream 
server can not handle the second media format then selecting a third media file having a 
third media format [Fig. 3 element 340; Spec, page 11, lines 21-25], determining if the 
quality of the selected media file is too high for the connectivity properties of the client 
[Fig. 3, element 350, Spec, page 12, lines 1-5], if the quality of the selected media file is 
too high transcoding the selected media file [Fig. 3, element 355; Spec, page 12, lines 3- 
5], generating a meta file for the selected stream server [Spec, page 12, line 6], and 
initiating streaming from the selected stream server [Spec, page 4, line 7]. 

In accordance with claim 14 a device for enhancing streaming operation in a 
distributed communication system is claimed. The device provides communication links 
between a plurality of stream servers, a client machine requesting a particular media file, 
and a stream server selection unit. The device is configured to perform a method 
according to claim 1 [for a summary of the elements of claim 14 please see summary of 
claim 1 above]. 

In accordance with claim 15 a computer program product is claimed. The 
computer program product is stored on a computer usable medium, comprising computer 
readable program means for causing a computer to perform a method according to claim 
1 [for a summary of the elements of claim 15 please see summary of claim 1 above]. 

Applicant believes the above satisfies the requirements of 37 C.F.R. §41. 37(c) (v). 
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6. Grounds of Rejection to be Reviewed on Appeal 

Claims 1, 3-5, 11, and 14-15 were finally rejected under §35 U.S.C. 103(a) as 
being upatentable over Rothman et al (Pub. No.: US 2001/0044851 Al), hereinafter 
"Rothman" in view of Murto et al. (Pub. No.: US 2004/0213409 Al), hereinafter 
"Murto". 

Claims 7, 9, and 12-13 were finally rejected under §35 U.S.C. 103(a) as being 
unpatentable over Rothman and Murto in further view of Kenner et al (Patent No.: US 
61 12239), hereinafter "Kenner". 

The only issue in this appeal is whether claim 1 is prima facie obvious over 
Rothman and Murto. 

Applicant believes the above satisfies the requirements of 37 C.F.R. §41. 37(c) 

(vi). 
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7. Argument 

Appellants content that the Examiner failed to establish adequate grounds of 
rejection for the following reasons: 



I. The Examiner improperly determined the scope and content of Rothman, and failed 
to ascertain the differences between claim 1 and Rothman in forming the § 103(a) 
rejection, [page 6] 

a. Rothman does not disclose key limitations, required in the "evaluating the 
list of stream servers by retrieving and considering the stream server's 
operating parameters" element, [page 6] 

b. Rothman does not disclose key limitations, required in the "retrieving and 
considering the format(s) in which the media file is presented" element, 
[page 8] 

c. Rothman does not disclose key limitations, required in the "retrieving and 
considering preferences from the client" element, [page 9] 

d. Rothman does not disclose key limitations, required in the "retrieving and 
considering the connectivity properties of the client" element, [page 10] 

e. Rothman does not disclose key limitations, required in the "determining if 
the selected stream server can handle the media format of a first media 
file" element, [page 1 1] 

f. Rothman does not disclose key limitations, required in the "converting the 
first media file to a second media file having a second media format" 
element, [page 12] 

g. Rothman does not disclose key limitations, required in the "transcoding 
the selected media file" claim element, [page 13] 
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I* The Examiner improperly determined the scope and content of Rothman, and 
failed to ascertain the differences between claim 1 and Rothman in forming the 
§103(a) rejection. 

Obviousness is a question of law based on underlying factual inquiries. 
Determining the scope and content of the prior art, and ascertaining the differences 
between the claimed invention and the prior art are two such inquiries. Graham Factors. 
To support the conclusion that the claimed invention is directed to obvious subject 
matter, either the references must expressly or impliedly suggest the claimed invention or 
the examiner must present a convincing line of reasoning as to why the artisan would 
have found the claimed invention to have been obvious in light of the teachings of the 
references. Ex parte Clapp, 227 USPQ 972, 973 (Bd. Pat App. & Inter. 1985). 

The Appellants submit that the Examiner failed to properly determine the scope 
and content of Rothman. Therefore the Examiner could not possibly ascertain the 
differences in claim 1 and the teachings of Rothman, nor could the conclusion of 
obviousness be supported expressly or implicitly by Rothman. Because the Examiner 
failed to properly determine the scope and content of Rothman, the examiner did not 
present a convincing reason for a conclusion of obviousness. Specifically the Examiner 
failed to properly determine the scope and content of Rothman, because: 

a. Rothman does not disclose key limitations, required in the "evaluating 
the list of stream servers by retrieving and considering the stream 
server's operating parameters" element. 

The claim elements, directly above, describe various factors of how a stream 
server is evaluated before a client and stream server connection is made, and before 
streaming of a media file is commenced. 



Serial No.: 10/616,526 

IBM Docket No.: DE92002001 1US1 



11 



In the final office action, the Examiner argues that the Rothman abstract teaches 
"retrieving and considering the stream server's operating parameters" by applying "where 
live, simulated live or looping programming, relayed streams and on demand media 
delivery function". Nothing in this passage has anything to do with considering the 
operating parameters of a stream server when evaluating which stream server to select for 
future streaming of a media file. 

However, Rothman teaches, "a controller server for applying an admission control 
policy to client requests and assigning stream servers to service the client requests." 
[0027, line 5-8]. Critically though, Rothman is silent as to the factors used in the 
"admission control policy." As Rothman simply states that an admission control policy 
exists, any interpretation of what factors the control policy utilizes would be beyond the 
scope of teachings of Rothman. The claim elements, "retrieving and considering the 
stream server's operating parameters, retrieving and considering the format(s) in which 
the media file is presented, retrieving and considering preferences from the client, 
retrieving and considering the connectivity properties of the client" are directed to 
evaluating the list of stream servers. Because Rothman does not at all consider this 
evaluation, it can not teach the evaluation claim elements in the correct context. Sure, 
Rothman may mention, "operating parameters/modes", but Rothman does not use 
operating modes for evaluating the list of stream servers in any way similar to the way 
contemplated by the Appellants in claim 1 . 

In this manner, Rothman teaches that a stream server may operate in four modes: 
basic/looping mode, live broadcasting mode, relay mode, on-demand mode. [Rothman 
0017-0021]. However nowhere does Rothman suggest that an evaluation of these 
operating parameters occurs to aid in the selection of a stream server. In fact Rothman 
teaches away from "evaluating the list of stream servers by retrieving and considering the 
stream server's operating parameters". Rothman assumes that all stream servers have 
identical operating parameters, since Rothman teaches that a stream server (generically) 
operates in different modes (i.e., all stream servers have the capability to operate in the 
same four operating modes). [Rothman 0017]. In other words, Rothman does not 
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consider utilizing stream servers each having the capability of operating in a completely 
different mode from the other stream server. Because each stream server contemplated in 
Rothman is identical to each other (each may operate in the four similar operating 
modes), evaluating the possible operating parameters of a potential stream server would 
not be necessary. 

Because Rothman does not expressly or implicitly teach, and in fact teaches away 
from, "evaluating the list of stream servers by retrieving and considering the stream 
server's operating parameters", the conclusion of obviousness can not be supported. 

b. Rothman does not disclose key limitations, required in the "retrieving 
and considering the format(s) in which the media file is presented" 
element. 

The claim elements, directly above, describe various factors of how a stream 
server is evaluated before a client and stream server connection is made, and before 
streaming of a media file is commenced. 

In the final office action, the Examiner argues that the Rothman abstract teaches 
"retrieving and considering the format(s) in which the media file is presented" by 
asserting the following passage: "where utilizing just-in-time play-list simulation, 
dynamic allocation of servers to listeners". The Examiner further sets forth that this 
passage describes the property that a request will be fulfilled according to specific 
preference as asked by client. 

The interpretation by the Examiner that "retrieving and considering the format(s) 
in which the media file is presented" has no clear link whatsoever with a "property that a 
request will be fulfilled according to specific preference as asked by client." The current 
application is considering the media file format (i.e., .mp3, .wav, etc.) available in a 
stream server before that stream server is selected and streaming is commenced. The 
consideration of media file format in the selection of a stream server is simply not 
contemplated by fulfilling a request according to specific preferences as asked by the 
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client, as the Examiner suggests. Nowhere does Rothman suggest that an evaluation the 
format(s) in which the media file is presented occurs to aid in the selection of a stream 
server. 

In fact Rothman teaches away from the evaluation of stream servers based on 
media formats to be presented from the stream server. Rothman only considers the 
situation where all the stream servers have "appropriate format" media files. Rothman 
teaches, "[t]he streaming data may include at least one of audio data, video data, 
multimedia data, text data, and/or any combination thereof in an appropriate format to be 
received and accessed by a user at the client." Rothman 0060, lines 12-16. Since all 
stream servers have "appropriate format" media files, then an evaluation of stream servers 
based upon media file formats is not necessary. Therefore, Rothman does not need to 
retrieve and consider the media file formats in the evaluation of each stream server, 
before a stream server is selected prior to streaming. 

Because Rothman does not expressly or implicitly teach, and in fact teaches away 
from, "evaluating the list of stream servers by. . . retrieving and considering the format(s) 
in which the media file is presented", the conclusion of obviousness can not be supported. 

c. Rothman does not disclose key limitations, required in the "retrieving 
and considering preferences from the client" element 

The claim elements, directly above, describe various factors of how a stream 
server is evaluated before a client and stream server connection is made, and before 
streaming of a media file is commenced. 

In the final office action, the Examiner argues that the Rothman Abstract teaches 
evaluating stream servers (to determine which stream server is utilized in streaming) by 
"retrieving and considering preferences from the client" by interpreting "delivering 
stream media by allocating specific server to specific client / listeners dynamically" as 
configuring preferences as per client requirements. In this manner, the Examiner 
improperly equates evaluating stream servers by retrieving and considering client 
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preferences (to aid in the selection of a stream server) to configuring preferences as per 
client requirements. 

Since the Examiner cited sentence is not actually in the Rothman Abstract, the 
Appellants assume that the following passage in the Rothman Abstract is what was meant 
to be written: "[t]he streaming server utilizes. . .dynamic allocation of servers to listeners". 

The interpretation by the Examiner that "retrieving and considering preferences 
from the client" has no clear link whatsoever with a "configuring preferences as per client 
requirements." The current application is considering client preferences when evaluating 
a list of stream server to select a stream server in order to commence streaming. The 
consideration of retrieving and considering client preferences (to aid in the selection of a 
stream server) is simply not contemplated by the general idea of dynamically allocating of 
stream servers, as the Examiner suggests. Nowhere does Rothman suggest that an 
evaluation of client preferences occurs to aid in the selection of a stream server. 

Because Rothman does not expressly or implicitly teach, "evaluating the list of 
stream servers by. . . retrieving and considering preferences from the client", the 
conclusion of obviousness can not be supported. 

d. Rothman does not disclose key limitations, required in the "retrieving 
and considering the connectivity properties of the client" element. 

The claim elements, directly above, describe various factors of how a stream 
server is evaluated before a client and stream server connection is made, and before 
streaming of a media file is commenced. 

In the final office action, the Examiner argues that the Rothman Abstract teaches 
evaluating stream servers (to determine which stream server is to be utilized in streaming) 
by "retrieving and considering the connectivity properties of the client" by interpreting 
"no load and low load control" as connectivity considerations. 

Rothman teaches a low load and a zero load method for efficient streaming. 
Rothman 0044 and 0045. However the low load and zero load methods for efficient 
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streaming have nothing to do with evaluating stream servers (to aid in the determination 
as to which stream server to select) by considering the connectivity properties between a 
client and each stream server. The low load and zero load methods involve the idea of 
allowing stream servers to not retrieve data from the storage system if the stream server 
has no client connections, Rothman [0043]. As stated above evaluation of a list of stream 
servers, by retrieving and considering the connectivity properties of the client, simply 
does not take place in Rothman. 

Because Rothman does not expressly or implicitly teach, "evaluating the list of 
stream servers by. . . retrieving and considering the connectivity properties of the client", 
the conclusion of obviousness can not be supported. 

e. Rothman does not disclose key limitations, required in the 
"determining if the selected stream server can handle the media 
format of a first media file" element 

The claim elements, directly above, describe that the selected stream server is 
evaluated to determine if the stream server can in fact stream a media file of a particular 
format. 

In the final office action the Examiner argues that the Rothman Abstract teaches 
"determining if the selected stream server can handle the media format of a first media 
file" by citing paragraph 0016 in Rothman. The Examiner states that generating a player 
window is an instance of the user's preferred web browser, and is equivalent to 
"determining if the selected stream server can handle the media format of a first media 
file." This assertion by the Examiner is simply not accurate. 

The aim for this particular claim element, is to determine if the selected stream 
server can handle a media file format (i.e., .mp3, .wav, etc.) before streaming is 
commenced. The consideration of whether a stream server can handle a type of media 
file format is simply not contemplated by "generating a player window", as the Examiner 
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suggests. Nowhere does Rothman suggest that an evaluation the format(s) in which the 
media file is presented occurs to aid in the selection of a stream server. 

In fact Rothman teaches away from determining if the selected stream server can 
handle the media format of a first media file. Rothman only considers the situation where 
all the stream servers have "appropriate format" media files. Rothman teaches, "[t]he 
streaming data may include at least one of audio data, video data, multimedia data, text 
data, and/or any combination thereof in an appropriate format to be received and accessed 
by a user at the client." Rothman 0060, lines 12-16. Since all stream servers have 
"appropriate format" media files, then determination whether a stream server can handle a 
first media file format is not necessary. 

Because Rothman does not expressly or implicitly teach, and in fact teaches away 
from, "determining if the selected stream server can handle the media format of a first 
media file", the conclusion of obviousness can not be supported. 

f. Rothman does not disclose key limitations, required in the 

"converting the first media file to a second media file having a second 
media format" element 

The claim elements, directly above, describe that the media file format is 
converted to another format if the selected stream server can not handle or stream the first 
media file format. 

In the final office action the Examiner argues that the Rothman teaches 
"converting the first media file to a second media file having a second media format" by 
citing paragraph 0060. The Examiner states that because Rothman teaches an 
"appropriate format to be received and accessed. . .at the client" implicitly describes that 
the server carry the functionality to use/change format according to specific requirements. 
This assertion of inherency is not supported factually or technically and is clearly 
improper. 
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To establish inherency, the extrinsic evidence must make clear that the missing 
descriptive matter is necessarily present in the thing described in the reference, and that it 
would be so recognized by persons of ordinary skill. Inherency, however, may not be 
established by probabilities or possibilities. The mere fact that a certain thing may result 
from a given set of circumstances is not sufficient. In re Robertson, 169 F.Sd 743, 745, 
49 USPQ2d 1949, 1950-51 (Fed, Cir. 1999). In relying upon the theory of inherency, the 
examiner must provide a basis in fact and/or technical reasoning to reasonably support the 
determination that the allegedly inherent characteristic necessarily flows from the 
teachings of the applied prior art. Ex parte Levy, 17 USPQ2d 1461, 1464 (Bd. Pat App. 
& Inter. 1990). 

The Examiners assertion of inherency is clearly based on probabilities or 
possibilities, and not because "converting the first media file to a second media file 
having a second media format" is necessary in Rothman. Rothman teaches that the media 
file format must be "appropriate" to stream. The possibility of having an inappropriate 
media file format is, simply and clearly, outside the scope of Rothman. It is certainly 
possible and highly probable that if Rothman was confronted with an inappropriate media 
file format, streaming would not occur. In other words it is not technically or factually 
necessary for Rothman to convert the media file format to an appropriate format. 
Therefore the Examiner's assertion of inherency is clearly in error. Consequently 
Rothman does not teach converting the first media file to a second media file having a 
second media format. 

Because Rothman does not expressly or implicitly teach, "converting the first 
media file to a second media file having a second media format", the conclusion of 
obviousness can not be supported. 

g. Rothman does not disclose key limitations, required in the 
"transcoding the selected media file" claim element. 



Serial No.: 10/616,526 

IBM Docket No. : DE9200200 1 1 US 1 



18 



In the final office action the Examiner argues that the Rothman teaches 
"transcoding the selected media file" by citing paragraph 0061 in Rothman. The 
Examiner states that Rothman teaches "transcoding", stating that in Rothman a "media 
file server 12 is a higher capacity and high availability network-attached data server 
configuration which provides the ability for multiple file systems to exist concurrently 
over multiple communication stacks with shared data access". 

Claim 1 requires transcoding (i.e., reducing the frame-rate or down-sampling the 
audio with standard algorithms. Spec, page 12, lines 3-5) the media file if the quality of 
the media file is too high for the connectivity properties of the client. 

Rothman teaches that each stream server has multiple physical file systems to co- 
exist, each optimized to the needs of a particular data service. [Rothman 0061, lines 11- 
13]. Consequently Rothman, is unlikely to utilize "transcoding" for connectivity issues, 
and is likely to utilize stream servers having multiple similar media files, each having a 
different quality, where the proper quality of media file may be selected to stream, 
depending on the connectivity properties of the client. In other words, because Rothman 
states that multiple files may exist on a stream server, there would be no need to 
transcode/degrade the quality of a particular file to due to connectivity issues. In this 
manner, Rothman teaches away from "transcoding" as contemplated by the Appellants. 

Because Rothman does not expressly or implicitly teach, and in fact teaches away 
from, "transcoding the selected media file", the conclusion of obviousness can not be 
supported. 

Summary 

Appellant discloses and claims a novel and unobvious method for enhancing 
streaming operation in a distributed communication system providing communication 
links between a plurality of stream servers, a client machine requesting a particular media 
file, and a stream server selection unit. Rothman, the primary reference, describes 
techniques for efficient streaming. For the reasons explained herein, Rothman fails to 
teach, and in fact teaches away from, the express limitations of claim 1. 
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Applicant believes the above satisfies the requirements of 37 €,FJ1. §41. 37(c) (vii). 
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8. Claims Appendix 

1 . (Previously Presented) A method for enhancing streaming operation in a 
distributed communication system providing communication links between a plurality of 
stream servers, a client machine requesting a particular media file, and a stream server 
selection unit, comprising the steps of: 

retrieving a list of stream servers from an Universal Description, Discovery, and 
Integration (UDDI) directory service, 

evaluating the list of stream servers by retrieving and considering the stream 
servers operating parameters, retrieving and considering the format(s) in which the media 
file is presented, retrieving and considering preferences from the client, retrieving and 
considering the connectivity properties of the client, 

selecting one of the stream servers on the list, 

determining if the selected stream server can handle the media format of a first 
media file, if the selected stream server can not handle the first media format, converting 
the first media file to a second media file having a second media format, 

determining if the selected stream server can handle the second media format, if 
the selected stream server can handle the second media format selecting the second media 
file, if the selected stream server can not handle the second media format then selecting a 
third media file having a third media format, 

determining if the quality of the selected media file is too high for the connectivity 
properties of the client, if the quality of the selected media file is too high transcoding the 
selected media file, 

generating a meta file for the selected stream server, and 

initiating streaming from the selected stream server. 

2. (Canceled) 

3. (Previously Presented) The method according to claim 1, wherein the step of 
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retrieving and considering the stream server's operating parameters further comprises the 
step of determining operating parameters of each stream server on the list of stream 
servers, wherein the operating parameters are formed by information about the supported 
media formats of the stream servers. 

4. (Original) The method according to claim 1 , wherein the step of evaluating the list of 
stream servers further includes the step of retrieving and considering the player 
availability. 

5. (Previously Presented) The method according to claim 1, wherein the step of 
retrieving and considering preferences from the client further comprises the steps of 
retrieving and considering a list of all available media players at the client, and retrieving 
and considering a preferred media player. 

6. (Canceled) 

7. (Original) The method according to claim 1, wherein the step of evaluating the list of 
stream servers further includes the step of weighting one or more of the considered 
parameters. 

8. (Canceled) 

9. (Original) The method according to claim 1, further comprising the step of 
determining whether or not the format of the media has changed. 

10. (Canceled) 

1 1 . (Previously Presented) A method for enhancing streaming operation in a 
distributed communication system providing communication links between a plurality of 
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stream servers, a client machine requesting a particular media file, and a stream server 
selection unit, comprising the steps of: 

retrieving a list of stream servers from an Universal Description, Discovery, and 
Integration (UDDI) directory service, 

evaluating the list of stream servers, 

selecting a stream server on the list, 

detecting the data transfer rate between the client machine and the distributed 

communication system, 

requesting the streaming of a media file in a first media file format, 
intercepting the request for streaming the media file if the stream server can not 

handle the first media file format, 

requesting the streaming of the media file in a second media file format, and 
sending the streaming request of the media file in a second media file format to 

the stream server selection unit. 

12. (Original) The method according to claim 11, further comprising the initial step of 
detecting the capabilities of the client machine. 

13. (Original) The method according to claim 1 1, further comprising the step of 
retrieving preferences predetermined by the user of the client machine. 

14. (Original) A device for enhancing streaming operation in a distributed 
communication system providing communication links between a plurality of stream 
servers, a client machine requesting a particular media file, and a stream server selection 
unit, the device being configured to perform a method according to claim 1. 

15. (Original) A computer program product stored on a computer usable medium, 
comprising computer readable program means for causing a computer to perform a 
method according to claim 1. 
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9. Evidence Appendix 

No evidence is submitted. 
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10. Related Proceedings Appendix 

There are no related proceedings. 
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